With the increasing expansion of the Internet, the existing IPv4 addresses composed of 32 bits are scarce. Accordingly, an IPv6 protocol employing an IP address of 128 bits has been proposed to thoroughly solve the problem of scarcity of the IPv4 addresses. IPv6 protocol has significant improvements on addresses capacity, security, network management, mobility and quality of service, etc. Before IPv6 protocol becomes the mainstream protocol, IPv4 protocol is continuously used, thus the coexistence of IPv4 network and IPv6 network occurs. In addition, due to imbalance of address allocation, some countries or regions still have enough IPv4 address space for allocation, thus IPv4 network will exist in these countries and regions for a long time. In a predictable future, IPv4 network and IPv6 network will coexist for a long time.
A situation exists today, which is an IPv4 application can not run in an IPv6 environment, and an IPv6 application can not run in an IPv4 environment. In addition, during transition from IPv4 to IPv6, since most of the existing applications are based on IPv4 protocol and IPv6 applications and services are relatively fewer than mature IPv4 applications and services, the IPv6 network resources are inevitably wasted.
In view of the above situation, the solution of enabling the existing IPv4 applications to run over the IPv6 network inevitably requires to be implemented. That is to say, it is desired to not only deploy new IPv6 networks, but also continue to use existing IPv4 application resources.
There are several solutions proposed in the prior art for the above problem. One is Dual Stack Transition Mechanism (DSTM). The object of DSTM is to solve the problem of connecting the dual stack hosts in the pure IPv6 network to the existing IPv4 hosts or applications. The gist of DSTM is to provide a measure for obtaining a temporal IPv4 address for an IPv6 node, and simultaneously add a gateway between the networks of different network protocols to achieve transmitting IPv4 traffic over the pure IPv6 network by using an IPv4 over IPv6 tunnel. This solution regards the IPv6 network as an IPv4 intranet, and thus is effective only in the intranet, and can not support an IPv4 address embedded application.
Another is an address translation mechanism, for example, Network Address Translator-Protocol Translator (NAT-PT); Bump in the Stack (BIS) and Bump in the API (BIA), etc. Under the address translation mechanism, the address of the IPv4 packet is translated into the IPv6 address and then transmitted in the IPv6 network, and vice versa. However, this translation mechanism inevitably results in large additional effort. In particular, when the IPv4 packet is embedded with an IPv4 address, an application gateway/proxy, etc, is required to translate the address embedded in the packet, which requires more translation amount and occupies more system resources. For example, for BIA, since it is required to transform the IP address (for example, FTP) embedded in the application layer protocol, such mechanism may be inapplicable to those new applications with addresses contained in their load.
A further solution is to modify the code for upgrading the IPv4 application to make the IPv4 application to be an IPv6 application, which requires re-coding and testing, and consumes time and efforts.
In the prior art, a DTTS technique has been proposed to solve the problem of running the IPv4 application over the IPv6 network. DTTS technique does not require NAT or application gateway/proxy, etc. However, DTTS occupies limited IPv4 address resources for allocating dynamic addresses when transforming the addresses, and transforms the IPv4 address into the IPv6 address by using an IPv4 compatible address when transforming the addresses, thus the transmitting apparatus needs 128-bit static routing configuration, which results in a heavy cost.